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1  Introduction 

The  Second  International  Workshop  on  Industrial- 
Strength  Formal  Techniques  (WIFT’98)  was  held  in  Oc¬ 
tober,  1998,  in  Boca  Raton,  Florida.  At  the  workshop, 
four  different  discussion  groups  investigated  various  top¬ 
ics.  This  report  summarizes  the  discussions  conducted 
on  the  topic  “Formal  Methods  for  Developing  High  As¬ 
surance  Systems.” 

High  assurance  computer  systems  are  computer  systems 
where  convincing  evidence  is  required  that  the  system 
satisfies  a  collection  of  critical  properties.  To  operate 
correctly,  these  systems  must  satisfy  properties  such  as 
safety  and  security.  Examples  of  high  assurance  systems 
include  flight  control  systems,  medical  systems,  and  con¬ 
trol  systems  for  nuclear  plants.  In  addition,  increased 
reliance  on  communications  is  moving  many  communi¬ 
cations  systems,  such  as  telephone  networks  and  cellular 
and  satellite  communications  systems,  into  the  domain 
of  high  assurance  systems. 

The  aim  of  the  1998  discussion  was  to  revisit  and  con¬ 
tinue  a  discussion  began  in  the  working  group  with  the 
same  name  at  the  first  WIFT  in  1995.  A  report  describ¬ 
ing  the  discussions  at  WIFT’95  is  available  at  the  web 
site: 

http://www.cse.msu.edu/WIFT98/ 

2  Discussion  Points 

During  WIFT’95,  the  following  topics  were  discussed: 

Advantages:  Where  and  how  have  formal  methods 
had  utility  in  the  development  of  high  assurance 
systems? 

Barriers:  What  are  the  major  barriers  to  applying  for¬ 
mal  methods  in  the  development  of  high  assurance 
systems? 

Strategies  for  Success:  How  can  we  obtain  an 
industrial-strength  process  for  developing  high  as¬ 
surance  computer  systems? 

Due  to  time  constraints,  some  topics  scheduled  for  dis¬ 
cussion  at  WIFT’95  never  were  addressed.  The  goal  of 


the  WIFT’98  discussion  was  to  revisit  the  above  topics 
and  also  to  address  the  following: 

Uses  of  Formal  Methods:  How  are  formal  methods 
being  used  in  the  development  of  high  assurance 
systems? 

Overcoming  the  barriers:  How  can  the  barriers  to 
widespread  use  of  formal  methods  be  overcome? 

The  summary  below  is  organized  around  these  two  top¬ 
ics  and  roughly  follows  the  flow  of  the  discussion  in  the 
group. 

3  Uses  of  Formal  Methods 

A  formal  method  may  be  described  as  an  approach  to 
developing  computer  systems  that  includes  1)  a  notation 
with  a  well-defined  syntax  and  semantics,  2)  some  guide¬ 
lines  and  procedures  for  using  the  notation,  and  3)  tech¬ 
niques  for  analyzing  specifications  expressed  in  the  nota¬ 
tion.  Traditionally,  formal  methods  have  been  used  for 
formal  specification  and  formal  verification.  Recently, 
the  use  of  formal  methods  for  refutation  has  also  gained 
widespread  use  in  some  segments  of  industry. 

Formal  Specification 

Formal  specification  of  the  required  system  behavior  has 
many  benefits.  For  example,  a  formal  specification  is 
unambiguous  and  precise,  can  be  checked  for  syntactic 
correctness,  and  can  help  ensure  that  a  specification  is 
well-formed. 

Formal  Verification 

A  formal  specification  enables  formal  verification.  In 
formal  verification,  a  proof  is  constructed,  often  with 
mechanical  support,  that  the  specification  satisfies  prop¬ 
erties  of  interest.  Several  projects  have  successfully 
applied  both  formal  specification  and  ’’light-weight” 
analysis  to  verify  well-formedness  properties  (e.g.,  type 
correctness,  no  missing  cases,  no  unwanted  nonde¬ 
terminism).  By  light-weight  analysis,  we  mean  me¬ 
chanical  analysis  that  is  largely  automated  or  semi- 
automated.  Examples  of  formal  methods  supporting 
both  formal  specification  and  light-weight  analysis  in¬ 
clude  SCR  (Software  Cost  Reduction)  [1,  2],  which 
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Ontario  Hydro  and  NRL  have  applied  in  real-world 
projects,  and  RMSL,  which  has  been  used  in  the  de¬ 
velopment  of  TCAS  II,  a  collision  avoidance  system  for 
aircraft  [3,  4,  5]. 

Usually  more  difficult  and  complex  than  verification  of 
well-formedness  properties  is  formal  verification  of  ap¬ 
plication  properties,  such  as  security  and  safety  prop¬ 
erties.  Despite  the  complexity  of  developing  formal 
proofs  of  application  properties,  however,  there  have 
been  numerous  successes.  Examples  include  the  veri¬ 
fication  of  the  floating  point  algorithm  for  division  in 
the  AMD5k86  microcode  [6],  verification  of  clock  syn¬ 
chronization  [7],  and  verification  of  a  collection  of  rep¬ 
resentative  instructions  for  the  AAMP5  processor  [8]. 

Refutation 

While  the  goal  of  verification  is  to  demonstrate  that  a 
specification  is  correct  with  respect  to  some  property, 
the  goal  of  refutation  is  to  find  errors  in  the  specifica¬ 
tion.  A  technique  called  model  checking,  which  auto¬ 
matically  checks  a  finite-state  machine  model  for  spec¬ 
ified  properties,  has  been  highly  successful  in  detect¬ 
ing  errors.  The  use  of  model  checkers  to  detect  de¬ 
fects  in  microprocessor  designs  is  now  common  in  in¬ 
dustry,  and  several  commercial  tools  are  available  to 
perform  this  task  [9],  In  addition,  some  microproces¬ 
sor  manufacturers  have  in-house  research  groups  devel¬ 
oping  proprietary  technologies.  The  success  and  util¬ 
ity  of  formal  methods  in  the  analysis  of  chip  design  is 
undisputed.  Reports  of  successful  application  of  model 
checking,  largely  to  detect  hardware  errors,  are  abun¬ 
dant  (see,  e.g.,  [10]). 

Why  the  success  in  hardware? 

Three  factors  related  to  the  success  of  formal  methods 
in  microprocessor  design  stand  out:  1)  the  high  cost 
of  design  mistakes,  2)  the  availability  of  standard  nota¬ 
tions,  and  3)  the  availability  and  use  of  tools,  such  as 
simulators. 

First,  the  cost  of  detecting  and  correcting  a  mistake  in  a 
chip  design  during  the  design  phase  is  low;  in  contrast, 
detecting  and  correcting  a  mistake  when  the  mask  is 
produced  or  when  the  chip  is  manufactured  is  very  high. 
Thus,  there  is  a  clear  cost  savings  associated  with  each 
mistake  detected  and  corrected  using  a  formal  method. 
This  cost  savings  provides  a  compelling  business  case 
for  using  formal  methods  technology  during  design. 

Second,  nearly  all  hardware  designers  use  one  of  two 
design  languages,  VHDL  or  Verilog  (see  Figure  1),  or  a 
variant.  Hence,  many  engineers  are  trained  to  use  these 
languages.  Further,  tools,  including  simulators  and  code 
synthesizers,  have  been  developed  for  designs  expressed 
in  these  languages.  This  defacto  language  standardiza¬ 
tion  provides  a  focal  point  for  research  and  commercial 
development  of  formal  analysis  tools. 


Ref:  C.  Heitmeyer.  Adopted  from  an  invited  talk  at  the  1 998  Symposium 
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Figure  1:  Formal  methods  in  hardware  design. 
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Figure  2:  Formal  methods  in  software  development. 
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In  the  domain  of  software  development  the  picture  is 
very  different.  First,  although  a  number  of  studies  have 
shown  that  significant  cost  savings  can  be  achieved  by 
detecting  software  errors  early  in  the  development  pro¬ 
cess  (see,  e.g.,  Boehm  [11]),  this  fact  is  not  widely  ac¬ 
cepted  among  software  practitioners.  The  common  ap¬ 
proach  is  to  detect  errors  during  the  later  development 
stages  (e.g.,  coding,  testing,  and  initial  operation).  Of¬ 
ten,  the  solution  to  a  software  bug  is  to  make  a  fix  avail¬ 
able  on  a  web  site  and  the  only  effect  is  a  minor  public 
relations  setback.  Thus,  an  explicit  business  case  is  lack¬ 
ing  for  using  formal  methods  in  software  development. 

Second,  the  number  of  different  modeling,  design,  and 
implementation  languages  used  in  software  development 
is  very  large;  nothing  close  to  a  standard  approach  to 
software  development  is  available  (Figure  2).  Further, 
tools  such  as  simulators  and  formal  analysis  tools  are 
rarely  used  during  the  initial  stages  of  software  devel¬ 
opment.  Unfortunately,  the  costs  of  training  engineers 
and  of  tool  development  are  very  high. 

Who  should  use  formal  methods? 

Formal  methods  may  be  used  in  two  ways:  1)  software 
practitioners  may  rely  on  formal  methods  experts  to 
apply  the  methods,  or  2)  practitioners  may  apply  the 
formal  methods  and  their  support  tools  directly.  Cur¬ 
rently,  the  former  is  the  dominant  approach.  In  indus¬ 
try,  formal  methods  are  perceived  as  very  difficult  to 
use.  (At  this  point  in  the  discussion,  industry  represen¬ 
tatives  pointed  out  that  they  are,  in  fact,  software  prac¬ 
titioners,  and  that  they  and  their  colleagues  use  formal 
methods.  Admittedly,  these  were  fairly  sophisticated  in¬ 
dustry  representatives  from  Praxis  Critical  Systems  and 
Collins  Commercial  Avionics,  but  they  pointed  out  sev¬ 
eral  examples  of  engineers  not  extensively  trained  in  for¬ 
mal  methods  using  sophisticated  formal  methods  tech¬ 
nology.  For  example,  formal  modeling  of  the  AAMP-FV 
microprocessor  at  Collins  was  performed  in  large  part 
by  the  microprocessor  designers.) 

For  formal  methods  to  have  a  large  impact  on  software 
development,  this  reliance  on  formal  methods  experts 
must  be  reduced  and  the  use  of  formal  methods  must 
become  standard  in  software  development.  Thus,  we 
should  strive  for  a  broad  dissemination  of  formal  meth¬ 
ods  knowledge  and,  like  the  hardware  community,  make 
formal  modeling  and  formal  analysis  part  of  standard 
practice. 

4  Overcoming  the  Barriers 

To  make  lasting  inroads  in  industry  and  to  put  formal 
methods  techniques  and  tools  in  the  hands  of  the  soft¬ 
ware  developers,  there  are  several  barriers  that  must  be 
overcome:  1)  the  notations  must  be  more  accessible  and 
easy  to  use,  2)  robust  tools  must  be  produced,  3)  edu¬ 
cation  must  be  improved,  and  4)  cost-effectiveness  must 


be  demonstrated. 

Notations  and  tools 

For  industrial  success,  the  traditionally  abstruse  no¬ 
tations  and  difficult-to-use  tools  produced  by  formal 
methods  research  must  be  abandoned.  There  is  little 
doubt  that  the  software  developers  in  industry  are  ca¬ 
pable  of  using  formal  methods;  if  they  can  learn  to  ef¬ 
fectively  use  C++,  they  can  learn  formal  modeling  and 
analysis.  What  is  needed  is  a  reduction  in  the  unnec¬ 
essary  complexity  introduced  by  poorly  designed  lan¬ 
guages  and  tools. 

The  importance  of  improved  notation  is  well  known, 
and  several  research  groups  are  addressing  the  problem 
[2,  3,  12,  13].  We  expect  new  and  easy  to  use  formal 
notations  to  emerge  in  the  next  few  years. 

Providing  robust  and  well-engineered  tools  is  a  more 
challenging  problem.  The  small  market  for  formal  meth¬ 
ods  tools  does  not  justify  the  high  cost  of  quality  tool 
development.  Most  tools  are  developed  in  research  en¬ 
vironments,  and  stability  and  ease  of  use  are  not  the 
highest  priorities.  Nevertheless,  as  the  penetration  of 
formal  modeling  in  industry  increases,  the  availability 
of  quality  tools  can  be  expected  to  follow. 

A  few  suggestions  tool  developers  should  consider  in¬ 
clude  the  following: 

•  Provide  more  automation. 

•  Provide  good  feedback  when  errors  are  detected. 
When  an  analysis  tool  detects  a  problem,  the  er¬ 
ror  report  must  clearly  identify  the  problem  in  the 
specification. 

•  Provide  tool  integration  and  tool  interoperability. 
Different  tools  are  good  for  different  tasks  and  must 
also  be  usable  in  concert.  There  should  be  no  need 
to  use  more  than  a  single  notation. 

•  Provide  simulators,  i.e. ,  tools  that  symbolically  ex¬ 
ecute  the  system  based  on  the  specification.  Inte¬ 
grating  a  simulator  into  a  formal  method  provides 
additional  inducement  for  industrial  users  to  apply 
a  formal  method. 

•  Integrate  methods  and  tools  into  the  software  de¬ 
velopment  process. 

Education 

Finding  the  time  for  formal  methods  education  in  the 
undergraduate  curriculum  is  a  challenge.  Computer  sci¬ 
ence  and  engineering  are  broad  topics,  and  many  stu¬ 
dents  (and  to  a  large  extent  industry)  are  simply  not 
interested  in  formal  methods  education.  Courses  in 
topics  such  as  graphics,  multimedia,  and  Internet  soft¬ 
ware  development  are  more  popular  and  are  perceived 
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Figure  3:  Technology  adoption  in  industry. 


to  have  more  direct  relevance  to  a  student’s  future  ca¬ 
reer.  Rigorous  software  development  (with  or  without 
formal  methods)  is  a  strenuous,  time-consuming,  and 
non-glamorous  activity.  Convincing  students  that  this 
activity  is  important  to  software  development  is  not  an 
easy  task. 

We  see  no  easy  solution  to  this  problem.  Hopefully,  as 
formal  methods  prove  their  worth  in  industry,  the  de¬ 
mand  for  and  availability  of  formal  methods  education 
will  increase. 

Provide  a  business  case  for  adoption 

If  we  can  show  that  the  use  of  formal  methods  reduces 
development  costs,  shortens  time  to  market,  and  in¬ 
creases  productivity,  management  is  much  more  likely 
to  adopt  the  approach.  The  success  of  model  checking 
and  equivalence  checking  in  the  hardware  community 
can  be  partially  credited  to  the  well-known  high  cost  of 
classes  of  design  problems  that  can  be  eliminated  using 
these  techniques.  If  we  can  provide  similar  evidence  in 
the  software  community,  widespread  adoption  of  formal 
methods  in  industry  is  more  likely  to  occur. 

5  Summary 

The  consensus  of  the  group  was  that  formal  methods  are 
mature  enough  to  be  applied  in  software  development. 
The  methods  have  proven  their  worth  in  numerous  in¬ 
dustrial  projects,  and  there  is  little  doubt  that  they  have 


an  important  place  in  the  software  development  process. 

Transferring  formal  methods  technology  to  industry  is 
largely  a  non-technical  problem  (it  is  often  a  culture 
clash)  and  the  transfer  is  happening  (slowly). 

The  group  agreed  that  there  have  been  few  major  break¬ 
throughs  in  formal  methods  usage  since  WIFT’95.  The 
one  notable  exception  is  the  increased  use  of  model 
checking  technology  in  microprocessor  design.  In  the 
hardware  community,  the  use  of  formal  methods  has 
moved  into  the  rapid  adoption  stage,  and  some  formal 
analysis  tools  have  become  part  of  the  standard  prac¬ 
tice. 

The  use  of  formal  methods  in  software  engineering  is 
currently  limited  to  the  early  adopters  (the  risk-tolerant 
users  in  Figure  3).  The  challenge  for  the  software  com¬ 
munity  for  the  next  few  years  is  to  follow  the  lead  of  the 
hardware  community  by  successfully  transferring  for¬ 
mal  methods  technology  into  the  development  of  high- 
assurance  software  systems. 
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